Changed to WIP, found several areas that presume a constant timestep in calculation of time I hadn't considered, like:

and

I am sure there are many others, so this probably is not as straightforward as I had thought.

@bigfooted Has there ever been any discussion regarding implementation of a START_TIME= capability into the config file? After going through the code a bit, it looks like doing this would be a good starting point for implementing ability to adjust deltaT mid-runs, as in general the code presumes TimeIter*deltaT as being the current time. This would be problematic for unsteady restarts that have a varying timestep. Plus, this would allow one to, without using the Python wrapper, use a different timestep in the config file for an unsteady restart. It also may clear up some confusion to have an explicit option for this, as in #2071.

It can maybe look something like:

% Start time for restarting unsteady simulations
% = -1 for default calculation (START_TIME=RESTART_ITER*TIME_STEP)
START_TIME=-1

Then CConfig::GetPhysicalTime could be appropriately updated and used in-place of all locations in the code where a physical time is manually calculated.

Sounds good to implement START_TIME for the restart issue. But for what you want to do it would be better to just accumulate the dts to compute physical time

Just want to leave some notes here, open to any thoughts or suggestions.

I think it's best to have it work something like this for 1st-order dual timestepping:

TIME_STEP=0.5
RESTART_ITER=0
----------------------------------------------------------------------
Time_Iter    Cur_Time
0                 0.0
1                 0.5
2                 1.0
----------------------------------------------------------------------
Output of restart_flow_00002.dat associated with t=1.0

Then if I want to restart that simulation but with a different timestep, I would have to make sure START_TIME represents the time at which the first iteration in the restart is completed to, NOT the time from the previous restart file:

TIME_STEP=0.25
RESTART_ITER=3
START_TIME=1.25
----------------------------------------------------------------------
Time_Iter    Cur_Time
3                 1.25

I think it may make more sense to just call it RESTART_TIME so it is consistent with RESTART_ITER.

However I don't think that this adaptive timestepping functionality / changing of timesteps for unsteady restarts would work for 2nd-order dual timestepping since information on the previous dt is lost. It wouldn't be too challenging to have a check for this in CDriver::SetUnsteadyTimestep and also a warning if START_TIME is used on an unsteady restart with it, but it may be getting a bit clunky at that point.

Closing this for now unfortunately - I will not have the time in the immediate future to work through intricacies of this. There are too many other features of SU2 that presume a dt*time_iter as the present physical time, so implementing this in a general way that accounts for these is a bit more tedious than I had expected.